Method and Apparatus for Maintaining Information at an Ims Client

ABSTRACT

A method, IP Multimedia Subsystem (IMS) client terminal, and Session Initiation Protocol (SIP) application server for synchronizing data stored at the IMS client terminal with data stored at the SIP application server. When the IMS client terminal sends a request to the SIP application server, the server determines whether the request includes information identifying the current state of the data stored at the client. If so, the server determines whether to send further data to the client based upon the information included in the request.

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for maintaininginformation at an IMS client and more particularly for maintainingup-to-date information at an IMS client.

BACKGROUND TO THE INVENTION

IP Multimedia services provide a dynamic combination of voice, video,messaging, data, etc., within the same session. By growing the number ofbasic applications and the media which it is possible to combine, thenumber of services offered to the end users will grow, and theinter-personal communication experience will be enriched. This will leadto a new generation of personalised, rich multimedia communicationservices, including so-called “combinational IP Multimedia” services.

IP Multimedia Subsystem (IMS) is the technology defined by the ThirdGeneration Partnership Project (3GPP) to provide IP Multimedia servicesover mobile communication networks (3GPP TS 22.228, TS 23.228, TS24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7).IMS provides key features to enrich the end-user person-to-personcommunication experience through the use of standardised IMS ServiceEnablers, which facilitate new rich person-to-person (client-to-client)communication services as well as person-to-content (client-to-server)services over IP-based networks. The IMS makes use of the SessionInitiation Protocol (SIP) to set up and control calls or sessionsbetween user terminals (or user terminals and application servers). TheSession Description Protocol (SDP), carried by SIP signalling, is usedto describe and negotiate the media components of the session. WhilstSIP was created as a user-to-user protocol, IMS allows operators andservice providers to control user access to services and to charge usersaccordingly.

By way of example, FIG. 1 illustrates schematically how the IMS fitsinto the mobile network architecture in the case of a GPRS/PS accessnetwork (IMS can of course operate over other access networks).Call/Session Control Functions (CSCFs) operate as SIP proxies within theIMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF(P-CSCF) which is the first point of contact within the IMS for a SIPterminal; the Serving CSCF (S-CSCF) which provides services to the userthat the user is subscribed to; and the Interrogating CSCF (I-CSCF)whose role is to identify the correct S-CSCF and to forward to thatS-CSCF a request received from a SIP terminal via a P-CSCF.

A user registers with the IMS using the specified SIP REGISTER method.This is a mechanism for attaching to the IMS and announcing to the IMSthe address at which a SIP user identity can be reached. In 3GPP, when aSIP terminal performs a registration, the IMS authenticates the user,and allocates a S-CSCF to that user from the set of available S-CSCFs.Whilst the criteria for allocating S-CSCFs is not specified by 3GPP,these may include load sharing and service requirements. It is notedthat the allocation of an S-CSCF is key to controlling (and chargingfor) user access to IMS-based services. Operators may provide amechanism for preventing direct user-to-user SIP sessions which wouldotherwise bypass the S-CSCF.

During the registration process, it is the responsibility of the I-CSCFto select an S-CSCF if a S-CSCF is not already selected. The I-CSCFreceives the required S-CSCF capabilities from the home network's HomeSubscriber Server (HSS), and selects an appropriate S-CSCF based on thereceived capabilities. [It is noted that S-CSCF allocation is alsocarried out for a user by the I-CSCF in the case where the user iscalled by another party, and the user is not currently allocated anS-CSCF.] When a registered user subsequently sends a session request tothe IMS, the P-CSCF is able to forward the request to the selectedS-CSCF based on information received from the S-CSCF during theregistration process.

There are a number of situations where an IMS client terminal will wantto maintain data which is substantially synchronised with datamaintained at a SIP application server. Consider for example a presenceservice, where IMS subscribers publish their presence information, e.g.current contact address, location, etc, in a database maintained at aSIP application server. This information is available to other usershaving appropriate access permissions. The exchange of informationbetween users and the SIP application server may be achieved using theSIP PUBLISH and SUBSCRIBE/NOTIFY methods.

SUMMARY OF THE INVENTION

As presently specified, the SIP SUBSCRIBE/NOTIFY method only allows anIMS client to request that it be notified of certain informationidentified in the SUBSCRIBE method. Thus, the identified informationwill be sent to the client in the NOTIFY message regardless of whetheror not the information has changed since the last time that the clientrequested the same information. The state of the art does not provideany mechanism for allowing only changed or new information to be sent tothe client.

According to a first aspect of the present invention there is provided amethod of substantially synchronising data stored at an IP MultimediaSubsystem client with data stored at a SIP application server of the IPMultimedia Subsystem, the method comprising:

-   -   receiving a request for said data, sent from the client, at the        application server;    -   determining whether or not the request contains a condition        identifying the current state of the data stored at the client;    -   on the basis of any identified condition, determining at the        application server whether or not to send further data to the        client; and    -   sending data in dependence upon the result of said        determination.

In an embodiment of the invention, said request is a SIP SUBSCRIBEmessage. Said condition may be contained in a SIP message header or inthe payload of the message.

In an embodiment of the invention, data is sent from the applicationserver to the client in a SIP NOTIFY message.

In an embodiment of the invention, if it is determined that the datacurrently stored at the client is up-to-date, the application serverinforms the client of this by sending one of a SIP NOTIFY or a 400series message.

The condition identifying the current state of the data stored at theclient may be one of a timestamp or version number. The condition mayhave been generated by the application server prior to or at the timethat the currently stored data was sent to the client by the applicationserver, or may have been generated by some other data source.

According to a second aspect of the present invention there is providedan IP Multimedia Subsystem client terminal comprising:

-   -   a memory for storing data together with a condition identifying        the current state of the data; and    -   means for generating and sending to a SIP application server of        the IP Multimedia Subsystem, a request to refresh the stored        data, the request including said condition.

According to a third aspect of the present invention there is provided aSIP application server comprising:

-   -   a memory for storing data together with a condition identifying        the current state of the data;    -   means for receiving from an IP Multimedia Subsystem client, a        request to refresh data stored at the client, the request        including a condition identifying the current state of the data        stored at the client;    -   means for comparing the received condition against the condition        stored for the data in said memory; and    -   means for sending the data stored at the application server to        said client if the conditions differ.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically the IMS architecture within a 3Gnetwork; and

FIG. 2 shows signalling associated with a data publishing and datarefresh procedure within the IMS.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

The general architecture of the IP Multimedia Subsystem (IMS) hasalready been described (FIG. 1) in the context of a 3G network. In anIMS based network it is possible for a client to request data about aresource in the network handled by different application servers. Theclient can either fetch data on a non-regular basis, it can poll thenetwork on a regular basis, or it can subscribe to changes that shouldbe sent to the client in more or less real time. Some clients mightprefer to use the former push solution where the network notifies theclient when a change in the requested data occurs. Other clients preferto fetch or poll for data only when it is needed. The IMS networksupports these functionalities with the provided Subscribe/Notifyframework (RFC 3265).

Considering the pull approach, in order to avoid the need to sendinformation that is already cached at an IMS client, it is proposed hereto include a new condition in the subscription request sent from theclient which indicates to the SIP application server the current statusof the cached data at the IMS client. This condition can be based ondifferent types of indicators such as a version number, a timestamp etc.The application server will check the condition included in thesubscription request and determine if the client has an up-to-dateversion of the data or not. In the case that the application serverdetermines that the cached data is up-to-date, the server will informthe client that the data is up-to-date and no actual data is sent. Ifthe server determines that the data stored in the client is obsolete,the server will send a notification including the updated data, oralternatively only the changes to the data. The notification will alsoinclude a condition that identifies the version of the new notification,e.g. version number or timestamp.

This behaviour is also possible for refresh subscription messages (thecurrent standardisation mandates the application server to always send afull notification to a client even if the client data is up-to date). Aclient making use of a push method, i.e. a client that creates a lastingsubscription with the application server, is required to periodicallyrefresh its subscription to keep the subscription active in theapplication server. Currently, when the client refreshes itssubscription (by sending a SUBSCRIBE with Expires>0), the applicationserver will return the stored data in a NOTIFY message. Application ofthe conditional mechanism described here allows such refresh to be donewithout the unnecessary download of data that is up-to-date. Thesolution is valid for any SIP-based subscription.

FIG. 2 illustrates the IMS related SIP signalling associated with aninformation exchange between two IMS clients, User A and User B, wheredata provided by User A is maintained at a SIP application server fordownloading by User B. User A uses the SIP PUBLISH method to send hisdata to the SIP application server (via the P-CSCF and S-CSCF) in steps1 to 3. In this example, it is assumed that at this stage User B has notreceived any version of User A's data. At step 4, User B requests UserA's data by sending a SUBSCRIBE message to the SIP application server.[The value of the “Expires” SIP header determines the method which theIMS client uses to obtain the data. “Expires=0” is used to fetch (pull)the data, while “Expires>0” is used to establish a subscription which isused to get changes in the data pushed to the client.] User B does notinclude in the SUBSCRIBE message any condition relating to User A'sdata. Upon receipt of the SUBSCRIBE message by the application server,the application server determines from the absence of a condition thatit must send all of User A's data to User B. It does this by includingthe data as payload in a SIP NOTIFY message, step 5.

At step 6, User B determines for some reason that it should contact theapplication server to determine if User A's data has been changed. Itdoes this by sending a further SUBSCRIBE message. However, this time itincludes in the message a condition identifying the current state ofUser A's data cached by User B. This condition is specified such that itcan be recognised by all parties, but may be included, for example, inthe SIP message header or in the payload. Based on the condition, theapplication server is able to determine whether the data held by itshould be sent to User B. In this example, as no change has been made tothe data, the application server returns to User B a “4xx” (i.e. 400series) message or an empty NOTIFY message.

Subsequently, User A sends a further PUBLISH message to the applicationserver containing updated data, steps 8 to 10. When User B sends afurther SUBSCRIBE message to the application server at step 11, itcontains a condition (“x”) identifying the current version of data heldfor User A. Upon receipt of the Subscribe message at the SIP applicationserver, the server determines from the condition x that the data held byUser B is obsolete. The server returns to User B, in a SIP NOTIFYmessage, the new data for User A.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiment withoutdeparting from the scope of the present invention.

1. A method of synchronizing data stored at an IP Multimedia Subsystemclient with data stored at a SIP application server of the IP MultimediaSubsystem, the method comprising: receiving at the application server, aSIP SUBSCRIBE request sent from the client, said request requesting datastored at the application serve; determining whether the requestcontains within a header thereof, an indication of the current state ofthe data stored at the client; if the request does not contain theindication, sending all of said data from the SIP application server tothe client within a SIP NOTIFY message; and if the request does containthe indication, determining at the application server, from thecondition, whether the data stored at the client differs from the datastored at the SIP application server and, if yes, sending the requesteddata to the client within a SIP NOTIFY message.
 2. The method accordingto claim 1, wherein, if it is determined that the data currently storedat the client is up-to-date, the application server informs the clientthat the client's data is up-to-date by sending one of an empty SIPNOTIFY or a 400 series message to the client.
 3. The method according toclaim 1, wherein the indication of the current state of the data storedat the client is one of a timestamp or version number.
 4. The methodaccording to claim 1, further comprising generating the indication ofthe current state of the data stored at the client by the applicationserver or another data source prior to or at the time that the currentlystored data was sent to the client.
 5. An IP Multimedia Subsystem clientterminal comprising: a memory for storing data together with anindication of the current state of the data; and means for generatingand sending to a SIP application server of the IP Multimedia Subsystem,a SIP SUBSCRIBE message to refresh the stored data, the messageincluding the indication.
 6. A SIP application server comprising: amemory for storing data together with an indication of the current stateof the data; means for receiving from an IP Multimedia Subsystem client,a SIP SUBSCRIBE requesting a refresh of data stored at the client, theSUBSCRIBE including an indication of the current state of the datastored at the client; means for comparing the received indicationagainst the indication stored for the data in said memory; and means forsending the data stored at the application server to said client in aSIP NOTIFY if the received indication differs from the storedindication.